Note ---  no matter any source code management system is used, it must make sure the correct branch is used.

1. 1. 4.3 Build Trigger 

The basic Git plugin offers the ability to Poll SCM on a timed basis, looking for changes since the last inquiry. If changes are found, a build is started. The polling log is accessible via a link on the left hand side of the page in the navigation bar when viewing a specific job. It offers information on the last time the repository was polled and if it replied with a list of changes .

After some build trigger plugin installed, Jenkins can get more advanced build trigger. For example,  we can add gerrit plugin, then any developer activities can trigger the building operations.

In a Freestyle build, there are three basic ways a build job can be triggered :

• •.Start a build job once another build job has completed  

• •.Kick off builds at periodical intervals  

• •.Poll the SCM for changes  

Schedule is based on CRON syntax, with some Jenkins' specific enhancement, it will be shown on the blue icon.

1. 1. 4.4 Build Step 

A build job may have one step, or more. It may even occasionally have none. In a freestyle build, you can add as many build steps as you want to the Build section of your project configuration

After we clicked on Build Step, several build steps will be shown, we can then choose Maven, Ant or Shell.

1. 1. 1. 4.4.1 Maven project 

For Maven Build Steps, Jenkins has excellent Maven support, and Maven build steps are easy to configure and very flexible. Just pick “Invoke top-level Maven targets” from the build step lists, pick a version of Maven to run.

Just like on the command line, you can specify as many individual goals as you want. You can also provide command-line options. A few useful Maven options in a CI context are:

-B, --batch-mode This option tells Maven not to prompt for any input from the user, just using the default values if any are required. If Maven does prompt for any input during the Jenkins build, the build will get stuck indefinitely.

-U, --update-snapshots Forces Maven to check for updated releases and snapshot dependencies on the remote repository. This makes sure you are building with the latest and greatest snapshot dependencies, and not just using older local copies which may not by in sync with the latest version of the source code.

-Dsurefire.useFile=false

This option forces Maven to write JUnit output to the console, rather than to text files in the target directory as it normally would. This way, any test failure details are directly visible in the build job console output. The XML files that Jenkins needs for its test reporting will still be generated.

After that, only Maven's target must be specified, such targets is list after run the mvn command in directory with pom.xml file. The commonly used Maven target includes,

• •test 

• •install 

• •package 

• •verify 

1. 1. 1. 4.4.2 Ant project 

Freestyle build jobs work equally well with Ant. Apache Ant is a widely-used and very well-known Java build scripting tool. Indeed, a very large number of Java projects out there rely on Ant build scripts.

Ant is not only used as a primary build scripting tool—even if your project uses Maven, you may resort to calling Ant scripts to do more specific tasks. There are Ant libraries available for many development tools and low-level tasks, such as using SSH, or working with proprietary application servers.

In its most basic form, configuring an Ant build step very is simple indeed—you just provide the version of Ant you want to use and the name of the target you want to invoke.  “Configuring an Ant build step”, for example, we are invoking an Ant script to run a JMeter test script.

1. 1. 4.5 Post Build Action 

Once the build is completed, there are still a few things you need to look after. You might want to archive some of the generated artifacts, to report on test results, and to notify people about the results. In this section, we look at some of the more common tasks you need to configure after the build is done.

1. 1. 1. 4.5.1 Test Reports 

One of the most obvious requirements of a build job is to report on test results. Not only whether there are any test failures, but also how many tests were executed, how long they took to execute, and so on. In the Java world, JUnit is the most commonly-used testing library around, and the JUnit XML format for test results is widely used and understood by other tools as well.

Jenkins provides great support for test reporting. In a freestyle build job, you need to tick the “Publish JUnit test result report” option, and provide a path to your JUnit report files . You can use a wildcard expression (such as**/target/surefire-reports/*.xml in a Maven project) to include JUnit reports from a number of different directories—Jenkins will aggregate the results into a single report.

1. 1. 1. 4.5.2 Archiving Build Result 

With a few exceptions, the principal goal of a build job is generally to build something. In Jenkins, we call this something an artifact. An artifact might be a binary executable (a JAR or WAR file for a Java project, for example), or some other related deliverable, such as documentation or source code. A build job can store one or many different artifacts, keeping only the latest copy or every artifact ever built.

Configuring Jenkins to store your artifacts is easy—just tick the “Archive the artifacts” checkbox in the Post-build Actions, and specify which artifacts you want to store.

1. 1. 1. 4.5.3 Notifications 

The point of a CI server is to let people know when a build breaks. In Jenkins, this comes under the heading of Notification.

Out of the box, Jenkins provides support for email notification. You can activate this by ticking the “E-mail Notification” checkbox in the Post-build Actions .Then enter the email addresses of the team members who will need to know when the build breaks. When the build does break, Jenkins will send a friendly email message to the users in this list containing a link to the broken build.

1. 1. 4.6 Ant 

Ant project can be easily added as a “free-style” project. Ant works quite well on Java build, but also can be used on other project, check the ant script syntax on ant.apache.org.

We can create build.xml int source code directory, with following contents,

<?xml version="1.0" encoding="UTF-8"?>

<project name="HermitLibrary" default="compile" basedir=".">

        <target name="compile" depends="init">

                <javac srcdir="${src.dir}" destdir="${classes.dir}" debug="yes"

                        includeantruntime="true">

                        <classpath refid="cobertura.classpath" />

                </javac>

        </target>

</project>

After that, in the same directory, type in ant will start compile operation. And such target can be specified in Ant Build Step.

1. 1. 4.7 Maven 

Maven build jobs are specifically adapted to Maven 2 and Maven 3 builds. Creating a Maven build job requires considerably less work than configuring the equivalent freestyle build job. Maven build jobs support advanced Maven-related features such as incremental builds on multimodule projects and triggering builds from changes in snapshot dependencies, and make configuration and reporting much simpler.

Maven project is driven by pom.xml,  Maven's POM file is more complicated than than Ant, but more flexible. Check maven.apche.org.

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<plugin>

        <groupId>org.apache.maven.plugins</groupId>

        <artifactId>maven-antrun-plugin</artifactId>

        <version>1.7</version>

        <executions>

          <execution>

            <id>ant-phase-compile</id>

            <phase>compile</phase>

            <goals>

              <goal>run</goal>

            </goals>

            <configuration>

              <target>

                <property name="mvn.project.build.outputDirectory" value="${project.build.outputDirectory}" />

                <property name="mvn.project.version" value="${project.version}" />

                <property name="mvn.compile_classpath" refid="maven.compile.classpath" />

                <ant antfile="ant-phase-compile.xml" />

              </target>

            </configuration>

          </execution>

          <execution>

            <id>ant-phase-verify</id>

            <phase>verify</phase>

            <goals>

              <goal>run</goal>

            </goals>

            <configuration>

              <target>

                <property name="mvn.project.build.directory" value="${project.build.directory}" />

                <property name="mvn.project.version" value="${project.version}" />

                <property name="mvn.runtime_classpath" refid="maven.runtime.classpath" />

                <ant antfile="ant-phase-verify.xml" />

              </target>

            </configuration>

          </execution>

        </executions>

        <dependencies>

          <dependency>

            <groupId>org.apache.ant</groupId>

            <artifactId>ant-nodeps</artifactId>

            <version>1.7.1</version>

          </dependency>

        </dependencies>

      </plugin>

</project>

After that, Maven will drive ant to run compile target.

1. 1. 4.8 Other Build Tool 

In the similar way, any other project and programming languages will be supported.

1. 5 Automated test 

Without using automated tests with your Continuous Integration setup, you’re really missing out on something big. Believe me—CI without automated tests is really just a small improvement on automatically scheduled builds. In short, if you are using Jenkins without any automated tests, you are not getting anywhere near as much value out of your Continuous Integration infrastructure as you should.

There are many ways you can integrate automated tests into your application. One of the most efficient ways to write high quality tests is to write them first, using techniques such as Test-Driven Development (TDD) or Behavior-Driven Development (BDD). In this approach, commonly used in many Agile projects, the aim of your unit tests is to both clarify your understanding of the code’s behavior and to write an automated test that the code does indeed implement this behavior. Focusing on testing the expected behavior, rather than the implementation, of your code also makes for more comprehensive and more accurate tests, and thus helps Jenkins to provide more relevant feedback.

1. 1. 5.1 Automating Test 

Jenkins does an excellent job of reporting on your test results. However, it is up to you to write the appropriate tests and to configure your build script to run them automatically. Fortunately integrating unit tests into your automated builds is generally relatively easy.

There are many unit testing tools out there, with the xUnit family holding a predominant place. In the Java world, JUnit is the de facto standard, although TestNG is another popular Java unit testing framework with a number of innovative features. For C# applications, the NUnit testing framework proposes similar functionalities to those provided by JUnit, as does Test::Unit for Ruby. For C/C+ +, there is CppUnit, and PHP developers can use PHPUnit.

1. 1. 5.2 Configuring Test Reports  

Once your build generates test results, you need to configure your Jenkins build job to display them. As mentioned above, Jenkins will work fine with any xUnit-compatible test reports, no matter what language they are written in.

For Maven build jobs, no special configuration is required—just make sure you invoke a goal that will run your tests, such as mvn test (for your unit tests) or mvn verify (for unit and integration tests). An example of a Maven build job configuration,

1. 1. 5.3 Display Test Results 

Once Jenkins knows where to find the test reports, it does a great job of reporting on them. Indeed, one of Jenkins’s main jobs is to detect and to report on build failures. And a failing unit test is one of the most obvious symptoms.

As we mentioned earlier, Jenkins makes the distinction between failed builds and unstable builds. A failed build (indicated by a red ball) indicates test failures, or a build job that is broken in some brutal manner, such as a compilation error. An unstable build, on the other hand, is a build that is not considered of sufficient quality.

“Jenkins displays test result trends on the project home page” we can see how Jenkins displays a Maven build job containing test failures. This is the build job home page, which should be your first port of call when a build breaks. When a build results in failing tests, the Latest Test Result link will indicate the current number of test failures in this build job, and also the change in the number of test failures since the last build. You can also see how the tests have been faring over time—test failures from previous builds will also appear as red in the Test Result Trend graph.

 

If you click on the Latest Test Result link, Jenkins will give you a rundown of the current test results,  “Jenkins displays a summary of the test results”. Jenkins understands Maven multimodule project structures, and for a Maven build job, Jenkins will initially display a summary view of test results per module. For more details about the failing tests in a particular module, just click on the module you are interest in.

When a test fails, you generally want to know why. To see the details of a particular test failure, just click on the corresponding link on this screen. This will display all the gruesome details, including the error message and the stack trace, as well as a reminder of how long the test has been failing. You should be wary of tests that have been failing for more than just a couple of builds—this is an indicator of either a tricky technical problem that might need investigating, or a complacent attitude to failed builds, which is more serious and definitely should be investigated.

1. 1. 5.4 Ignoring Tests 

Jenkins distinguishes between test failures and skipped tests. Skipped tests are ones that have been deactivated, for example by using the @Ignore annotation in JUnit 4:

@Ignore("Pending more details from the BA")

@Test

public void cashWithdrawalShouldDeductSumFromBalance() throws Exception {

    Account account = new Account();

    account.makeDeposit(100);

    account.makeCashWithdraw(60);

    assertThat(account.getBalance(), is(40));

}

1. 1. 5.5 Code Coverage 

Code coverage gives an indication of what parts of your application were executed during the tests. While this in itself is not a sufficient indication of quality testing (it is easy to execute an entire application without actually testing anything, and code coverage metrics provide no indication of the quality or accuracy of your tests), it is a very good indication of code that has not been tested. And, if your team is introducing rigorous testing practices such as Test-Driven-Development, code coverage can be a good indicator of how well these practices are being applied.

Cobertura is an open source code coverage tool for Java and Groovy that is easy to use and integrates well with both Maven and Jenkins.

Like almost all of the Jenkins code quality metrics plugins, the Cobertura plugin for Jenkins will not run any test coverage metrics for you. It is left up to you to generate the raw code coverage data as part of your automated build process. Jenkins, on the other hand, does an excellent job of reporting on the code coverage metrics, including keeping track of code coverage over time, and providing aggregate coverage across multiple application modules.

1. 1. 1. 5.5.1 Cobertura for Ant 

Cobertura comes bundled with an Ant task that you can use to integrate Cobertura into your Ant builds. You will need to download the latest Cobertura distribution, and unzip it somewhere on your hard disk.

To make your build more portable, and therefore easier to deploy into Jenkins, it is a good idea to place the Cobertura distribution you are using within your project directory, and to save it in your version control system. This way it is easier to ensure that the build will use the same version of Cobertura no matter where it is run.

     <path id="cobertura.classpath">

                <fileset dir="${cobertura.dir}">

                        <include name="cobertura.jar" />

                </fileset>

        </path>

        <target name="instrument" depends="init,compile">

                <delete file="cobertura.ser"/>

                <delete dir="${instrumented.dir}" />

                <cobertura-instrument todir="${instrumented.dir}">

                        <ignore regex="org.apache.log4j.*" />

                        <fileset dir="${classes.dir}">

                                <include name="**/*.class" />

                                <exclude name="**/*Test.class" />

                        </fileset>

                </cobertura-instrument>

        </target>

        <target name="coverage-check">

                <cobertura-check branchrate="34" totallinerate="100" />

        </target>

        <target name="coverage-report">

                <cobertura-report srcdir="${src.dir}" destdir="${coverage.xml.dir}" format="xml" />

        </target>

1. 1. 1. 5.5.2 Cobertura for Maven 

Producing code coverage metrics with Cobertura in Maven is relatively straightforward. If all you are interested in is producing code coverage data, you just need to add the cobertura-maven-plugin to the build section of your pom.xml file:

<project>

    ...

    <build>

        <plugins>

            <plugin>

                <groupId>org.codehaus.mojo</groupId>

                <artifactId>cobertura-maven-plugin</artifactId>

                <version>2.5.1</version>

                <configuration>

                    <formats>

                        <format>html</format>

                        <format>xml</format>

                    </formats>

                </configuration>

            </plugin>

            ...

        </plugins>

        <build>

            ...

</project>

This will generate code coverage metrics when you invoke the Cobertura plugin directly:

$ mvn cobertura:cobertura

The code coverage data will be generated in the target/site/cobertura directory, in a file called

coverage.xml.

Then we can check the result as,

1. 1. 5.6 Code quality 

Before we look at how to report on code quality metrics in Jenkins, it can be useful to take a step back and look at the larger picture. Code Quality metrics are of limited value in isolation—they need to be part of a broader process improvement strategy.

The first level of code quality integration should be the IDE. Modern IDEs have great support for many code quality tools—Checkstyle, PMD, and FindBugs all have plugins for Eclipse, NetBeans, and IntelliJ, which provide rapid feedback for developers on code quality issues. This is a much faster and more efficient way to provide feedback for individual developers, and to teach developers about the organizational or project coding standards.

1. 1. 1. 5.6.1 Checkstyle 

Checkstyle is a static analysis tool for Java. Originally designed to enforce a set of highly-configurable coding standards, Checkstyle now also lets you check for poor coding practices, as well as overly complex and duplicated code. Checkstyle is a versatile and flexible tool that should have its place in any Java-based code quality analysis strategy.

Checkstyle supports a very large number of rules, including ones relating to naming conventions, annotations, javadoc comments, class and method size, code complexity metrics, poor coding practices, and many others.

        <target name="checkstyle" depends="compile">

                <mkdir dir="test-reports/checkstyle-xml" />

                 <checkstyle config="config/custom-checkstyle.xml">

                    <fileset dir="src" includes="**/*.java"/>

                        <formatter type="xml" toFile="test-reports/checkstyle-xml/checkstyle-result.xml"/>

                  </checkstyle>

        </target>

If such checkstyle project is added into Jenkins, then the project can be shown with automatic checkstyle step. After install CheckStyle Plugin, then and the project build summary will be like,

 

And also with more detail after we click specific warning.

 

 

1. 1. 1. 5.6.2 PMD 

PMD is another popular static analysis tool. It focuses on potential coding problems such as unused or suboptimal code, code size and complexity, and good coding practices. Some typical rules include “Empty If Statement,” “Broken Null Check,” “Avoid Deeply Nested If Statements,” “Switch Statements Should Have Default,” and “Logger Is Not Static Final.” There is a fair amount of overlap with some of the Checkstyle rules, though PMD does have some more technical rules, and more specialized ones such as rules related to JSF and Android.

 

Add it to ant's build.xml

    <path id="pmd.classpath">

        <pathelement location="org.apache.maven.model.Build@6da706b0"/>

        <fileset dir="lib/pmd">

            <include name="*.jar"/>

        </fileset>

    </path>

    <taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask"

        classpathref="pmd.classpath"/>

    <taskdef name="cpd" classname="net.sourceforge.pmd.cpd.CPDTask"

        classpathref="pmd.classpath"/>

   

    <target name="pmd">

        <taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask"

        classpathref="pmd.classpath"/>

        <pmd rulesetfiles="basic" shortFilenames="true">

            <formatter type="xml" toFile="target/pmd.xml" />

            <fileset dir="src/main/java" includes="**/*.java"/>

        </pmd>

    </target>

 

After that, the result report page is similar to checkstyle. After installed PMD report plugin,

then we can get the PMD report project.

 

1. 1. 1. 5.6.3 FindBugs 

 

FindBugs is a powerful code quality analysis tool that checks your application byte code for potential bugs, performance problems, or poor coding habits. FindBugs is the result of research carried out at the University of Maryland lead by Bill Pugh, that studies byte code patterns coming from bugs in large real-world projects, such as the JDKs, Eclipse, and source code from Google applications. FindBugs can detect some fairly significant issues such as null pointer exceptions, infinite loops, and unintentionally accessing the internal state of an object. Unlike many other static analysis tools, FindBugs tends to find a smaller number of issues, but of those issues, a larger proportion will be important.

 

Integrate Findbugs with Ant,

 

        <target name="findbugs" depends="compile">

                <mkdir dir="test-reports/findbugs-xml" />

                <findbugs home="${findbugs.home}" output="xml" outputFile="test-reports/findbugs-xml/findbugs-report.xml">

                           <class location="${classes.dir}" />

                    <auxClasspath refId="dependency.classpath" />

                    <sourcePath path="src" />

                  </findbugs>

        </target>

 

After FindBug reports plugin installed, we will get report pages,

 

 

After click FindBugs Warnings, it will change the Warning summary page. After click the detailed warning, it shows the issue,

 

 

TODO,

 

1. 6 Security 

2. 7 Plugin 

3. 8 Generate reports 

4. 9 Extensibility 

5. 10 Mantenancy